Power Tools 1993 October - Disc 2/Power Tools (Disc 2)(October 1993)(HP).iso/hotlines/ccsyhl/sisapint/sisapint.txt

Text File | 1993-05-21 | 40KB | 809 lines

Application Integration Using HP Software
Integration Sockets








1.0     Introduction

This document provides technical guidance as you create a solution of
integrated applications using HP Software Integration Sockets (HP
Sockets). It covers the steps to take during your design and
development process, including several important decisions to make
during the process, and many helpful hints to make your development of
an HP Sockets-based solution as smooth as possible. It also covers the
writing of a full functioned adapter for an application independent of
a specific integrated solution. One example is used throughout this
document to further illustrate each step in the design and development
process.

Application Integration Using HP Software Integration Sockets is one
piece of the HP Sockets documentation set. It should be used in
conjunction with the product manuals listed in the HP Sockets
documentation roadmap in the last chapter.


2.0     Application Integration

Integrating applications allows two or more independent applications to
behave like ONE application, sharing information and control
transparent to the user of the integrated applications. To achieve this
level of integration, you must understand the features you want in the
integrated solution and have detailed knowLedge of the applications
data import/export mechanisms and their data formats. Many design
decisions that have to be made during the application integration
process will be based on this knowledge.

The following flow chart outlines the design and development process
for creating an integrated solution using HP Sockets. As you can see,
there are many places where you may have to iterate on the design,
based on new knowledge. The more detailed application knowledge you
have at the start of the process, the fewer iterations will be required
to complete the design.

The remainder of this document walks you through the steps of the
application integration process.


*** Object: Untitled


3.0     Application Integration Steps

This chapter walks you through each of the application integration
steps that you will use in your integration project as shown in the
previous flow chart.

As we go through the steps, we will discuss the creation of an
integrated solution to demonstrate the concepts and design decisions
presented here. Our example solution uses a Material Resource Planning
(MRP) application, a Scheduling application, and a Factory Control
application. Before being integrated, the Scheduling application uses
the data from a product plan that was manually entered to determine a
production schedule which is sent to the Factory Control application.
In the integrated solution, the Scheduling application will use up-to-
date finished goods inventory and stock level data from the MRP
application, in addition to the product plan also from the MRP
application, to create a better production schedule that is sent
directly to the Factory Control application which will get the
appropriate recipes from the MRP application to put the schedule into
production. This integrated solution requires less manual entry and
uses and provides more up-to-date information.

3.1     Story Board the Integrated Solution

The decision to create an integrated solution often springs from
someone's insight into their business such as "My factory could run
more efficiently if the scheduler knew when new customer orders arrived
and could adjust the production schedule accordingly" or "I could
better satisfy my customers if I could get them product availability
data on time." The creation of a solution to realize the in sight
usually involves integrating data between two or more existing
applications and possibly even with applications being written
specifically for the new solution.

The questions that should be answered at this step of the project have
little to do with HP Sockets but rather focus on the problem at hand,
what functions are required to create the solution to the problem, and
how the resulting solution should behave:

What is the goal of the integrated solution? What applications will you
use to create the integrated solution? What are the high level
functions that you want the integrated solution to perform?

3.1.1   Example

The goal of our example integrated solution is to allow the re-
evaluation of the master production plan on a weekly basis, using up-
to-date inventory levels and the latest product plans, to create and
automate the distribution of the daily production schedule and
production recipes, and to report back on raw material consumption.

The applications necessary to create the integrated solution are:

        Materials Resource Planning application (MRP) Scheduling
        application (SCHD) Factory Control application (FC)

The high level functions of the integrated solution are:

On a weekly basis: Create a master production plan (26 week plan)
Optimize the production plan Release the new production plan to the
resource planner Do the materials resource planning

On a daily basis: Create a production schedule (5 day plan) Optimize
the production schedule Release the production schedule to
manufacturing Get production recipes to implement production schedule

On an ongoing basis: Update material consumption

3.2     Define High Level Data Flows

Once the high level functions of the integrated solution have been
defined as part of the story board, the applications to perform those
functions and the external data they require can be defined. The
questions that should be answered at this step provide the information
for you to draw a high level data flow diagram of the integrated
solution.

This diagram together with the story board from the previous step
should be used to verify the correctness and completeness of the
solution with your customers. For each of the high level functions that
were enumerated in the story board, answer these questions:

Which application will perform the function?  What data is required for
that application to perform the function?  Where is that data produced
and consumed?

A nice way to represent this information is to create a data flow table
and diagram that work in conjunction with one another. The table
summarizes the data required to implement each high level function and
the providing and consuming applications. The data flow diagram is a
pictorial depiction of that same data.

3.2.1   Example

In our example, each high level function has an entry in the data flow
table in this format:

Function #: <function description> - <application performing the
function> Data
        Flow #: <type of data> - <data producer> -> <data consumer>...
        <enumerate all data flows required to implement the function>

For our example, the data flow table and diagram that correspond to the
list of functions defined in section 3.1.1 follows:

Function 1: Create a master production plan - SCHD Data Flow 1A.
Product plan - external source -> SCHD Data Flow 1B. Finished Goods
Inventory - MRP -> SCHD
Function 2: Optimize the production plan - SCHD All necessary data is
local to the SCHD application
Function 3: Release the new production plan to resource planning - SCHD
Data  Flow 3A. Production Plan  -  SCHD -> MRP
Function 4: Do the materials resource planning - MRP All necessary data
is local to the MRP application
Function 5: Create a production schedule - SCHD Data Flow 5A.
    Stock Levels - MRP  -> SCHD Data Flow 5B. Orders - MRP -> SCHD
Function 6: Optimize the production schedule - SCHD All necessary data
is local to the SCHD application
Function 7: Release the production schedule to manufacturing - SCHD
Data Flow
     7A. Production schedule - SCHD -> MRP Data Flow
     7B. Production schedule - SCHD -> FC
Function 8: Get production recipes to implement production schedule -
FC Data Flow 8A. Recipe- MRP -> FC
Function 9: Update material consumption - FC Data Flow 9A. Material
    consumption - FC -> MRP



*** Object: Untitled



3.3     Define Data Control and Access

After determining the high level data flows, you are now ready to start
creating the data flow specifications for the integrated solution. This
step examines how the data required to perform each function is
accessed and controlled. This examination breaks down into four
different questions to be answered:

Will the data be "pulled" by the consuming application from its
producing application or will it be "pushed" from the producing
application to the consuming one? What determines when this data "push"
or "pull" happens? Where will the data be stored at the producing and
consuming application? What mechanism will be used to access the data
at the producing application and store the data at the consuming
application?

Deciding whether the data should be "pushed" or "pulled" is usually
based on what triggers the movement of the data. For example, the start
of a high level fun ction could be triggered by a user operation, a
scheduled time, or a solution-based event. The application that
receives the trigger to start a function will generally be in charge of
moving the data - it will "push" the data if it is the data producing
application or "pull" the data if it is the data consuming application.

You also need to understand the basic data storage and access
mechanisms of the applications to determine where and how the necessary
data can be obtained and stored. The data may be stored in internal
tables, a database, a file, etc. The data may be accessed by using the
application program interface (API) provided by the application, the
application\xd5s import and export mechanisms, data base access calls,
the application\xd5s 4th Generation Language (4GL), etc.

This step and the two following ones will result in the data flow
specification for the integrated solution. The best way to represent
this information is to start filling in a specification for each of the
high level data flows. Here is a suggested data flow specification
format:

Data Flow: <number> /* from high level data flow design */ Name: <name>
/* from high level data flow design */ Push/Pull: <push/pull> /* from
data control and access design */ Trigger: <trigger type> /* from data
control and access design */ Source: <data source and access mechanism>
/* from data control and access design */ Destination: <data
destination and access mechanism> /* from data control and access
design */ Transfer Mechanism: <message/file & data transfer action
list> /* from adapter d esign */ Source Data Format: <data description>
/* from detailed data definition design * / Destination Data Format:
<data description> /* from detailed data definition design */ Data
Manipulation: <none/HP Sockets (specify source and destination
programming languages) /adapter> /* from detailed data definition
design */

3.3.1   Example

For this example, we will examine three of the data flows in detail -
1B, 3A, an d 8A.

Data Flow 1B The SCHD application performs function 1 by creating a
master production plan using the product plan and finished goods
inventory data. Since this function is triggered by an operator at the
console of the SCHD application, the Finished Goods Inventory (FGI)
data is "pulled" from the MRP application to the SCHD application. Here
is a partial specification for data flow 1B:

Data Flow: 1B Name: Finished Goods Inventory (FGI) Push/Pull: Pull
Trigger: SCHD Operator Source: MRP database accessed by procedures
written in MRP 4GL Destination: SCHD in memory table accessed by SCHD
batch import mechanism

Data Flow 3A The SCHD application also performs function 3 which
releases the new production plan to resource planning. Since this
function is triggered when the production plan is completed, the plan
is "pushed" from the SCHD to the MRP application.  Here is a partial
specification for data flow 3A:

Data Flow: 3A Name: Production Plan Push/Pull: Push Trigger: Solution-
based event: completion of production plan Source: SCHD in memory table
accessed by SCHD batch export mechanism Destination: MRP database
accessed by procedures written in MRP 4GL

Data Flow 8A The FC application performs function 8 which retrieves new
production recipes from the MRP application if they are needed. Since
this function is triggered whe n the evaluation of a new production
schedule shows that the FC application does not have all of the
necessary recipes, the recipe is "pulled" from the MRP to the FC
application. Here is a partial specification for data flow 8A:

 Data Flow: 8A Name: Recipe Push/Pull: Pull Trigger: Solution-based
event: evaluation of the production schedule Source: MRP database
accessed by procedures written in MRP 4GL Destination: FC shared memory
accessed by procedures written in FC 4GL


3.4     Design Adapters

In this step, you need to design one or more adapters for each
application in the solution based on the high level functions it needs
to perform, the data it needs to produce and/or consume, and the data
access mechanisms it provides. You do not have to design the format of
the messages being passed between the adapters. The HP Sockets Program
has defined a message format to be used to ensure that adapters written
independently will be able to communicate. Refer to the HP Software
Integration Sockets Standard Message Format document for the definition
of that standard format.

The adapter design process will most likely be iterative as you gain
more knowledge of the applications and the operation of the final
solution. In the end, the three main design questions that need to be
answered for each application in the solution are:

How many and what type of adapters are required? How often will those
adapters run and how will they be started? What are the data transfer
requirements of each of those adapters?


3.4.1   Adapter Types

An adapter can have one or more of the following types:

        "receive" (a server adapter) "send" "send and
        receive" "task sequencing"

A "receive" adapter waits for a request to be made of its application
from another HP Sockets adapter, communicates with its application to
fulfill the request, and begins to wait again for the next request.
This waiting can be performed by calling SpReadQ with an infinite
timeout or setting up file and message notification with SpControl and
signal handlers so the adapter receives a signal when a request comes
in. The simpler implementation is using the infinite wait since it
avoids having to write robust signal handlers.

If the "receive" adapter gets a request to store incoming data, the
data storage mechanisms of the application are used to store the data.
If the request is to provide data, it can be implemented in a variety
of ways depending on the robustness of the external interface provided
by the application. If the application allows you to add your own
functionality to it (by compiling in functions you have written or
providing scripts or 4GL functions to call), you can pass the data
request to this function and the "receive" adapter can continue its
main job of waiting for incoming requests. In this case, the functions
you have written will extract the requested data from the application
and use a "send" adapter to get the information to the correct
application. A "send" adapter waits for an application trigger before
sending a message or data out to another application using HP Sockets.
This application trigger can be a message sent to the adapter using an
interprocess communication mechanism, a function call if you can link
the send adapter into the application, the actual invocation of the
send adapter, etc.

A "send and receive" adapter will have to perform both functions of
receiving or sending a request or data. This type of adapter can be
created using the message notification capability of HP Sockets which
will allow it to receive messages as they arrive even if it is engaged
in another task. The adapter will spend its time processing requests or
data from its application or another application via HP Sockets. It
should have a queue to hold all of these requests that it will process
appropriately. This is basically the "send" aspect of the adapter. The
"receive" aspect of the adapter is implemented by a signal handler that
is in voked by HP Sockets when a message has arrived for the adapter.
That signal handler can either read the messages from its HP Sockets
queue until it is empty or it can read a predetermined number of
messages. It then puts the requests into the adapter queue to process
in turn with the other requests being made of the adapter.


A "task sequencing" adapter is one that starts and stops other adapters
or processes to make sure that a certain task is performed. An adapter
that sequences tasks may also be a receive and/or send adapter.

3.4.2   Adapter Running

For each adapter in the integrated solution, you have to decide how it
should be initially started. Depending on the needs of the solution,
adapters can be started by their applications, by a script run when the
integrated solution is started or by another adapter using the
SpStartProcess access routine.

Regardless of how the adapter is initially started, you need to write
the adapter to handle the situation of HP Sockets being stopped while
the adapter is running. Here are a few possible scenarios:

 *  Bracket each section of code that uses HP Sockets access routines
with calls to SpInit and SpEnd. If the SpInit fails, the piece of code
is not executed and an error handling section can be executed. Due to
the overhead of calling SpIni t and SpEnd, this is only a good solution
if the adapter does not spend a lot of time calling HP Sockets access
routines.
 * Call SpInit at the start of the adapter and check the results of
each HP Socke ts access routine call to see if an error is returned. If
an error indicating that HP Sockets is down is returned, go to a
section of code that tries to re-establish connection with HP Sockets
every few seconds or end the adapter and have the system administrator
manually re-start it when HP Sockets is re-started.

3.4.3   Data Transfer

In the "Define Data Control and Access" step, you investigated the
source and de stination for each data flow and the mechanisms available
to access the data. Now you must take that investigation one step
further and decide whether the data will be transmitted as a message or
a file and whether any additional data transfer mechanisms are required
to get the data from its source to its destination.

Sending data in a message allows you to take advantage of the HP
Sockets data manipulation capability, provides more features for the
transfer of the data including sending the message as critical or
guaranteed, and results in faster data transfer than using files. If
the source data is in a file but you want to benefit from sending the
data as a message, simply have the adapter read in the file a record at
a time and send the data as a message. If you are transferring large
amounts of data or data that needs to be stored as a file at both the
source a nd destination side, use the HP Sockets file transfer
facility.

Additional data transfer mechanisms will have to be coded in your
adapter if intermediate steps are required to produce or consume the
data. For example if an application provides a batch interface to
respond to requests for data, the adapter for that application may have
to read the incoming message from HP Sockets and invoke the correct
batch function to get the data.

At the end of this step you should have a System Overview diagram
showing all of the adapters and applications that will make up your
integrated solution. For each data flow, you should also fill out the
Transfer Mechanism field in the data flow specification.

3.4.4   Example

In our example, the SCHD application can only import and export data
via files so we will write two adapters and an auxiliary program to
integrate it into the solution. One adapter is a "receive" adapter,
which is started when the solution is brought up, to wait for incoming
requests. As the requests arrive, it creates a file for SCHD requesting
an action. The auxiliary program polls for files being created by the
"receive" adapter, moves the files to the correct place for SCHD, and
interactively notifies the SCHD operator that data has arrived. The
second adapter, the "send" adapter, is started by the SCHD application
whenever data needs to be sent out from SCHD to another application.

The MRP application provides two features that we will take advantage
of when writing our HP Sockets adapters. First, it provides read and
write functions to access its database which can be invoked by sending
a request to its Interface Manager. The communication between the
Interface Manager and the HP Sockets "receive" adapter is via a pipe
set up by the Interface Manager when the MRP application and "receive"
adapters are started. Second, the MRP application allows you to link
code into its program. We will use that feature to link in an HP
Sockets "send" adapter which is started by the Interface Manager for
any data requests made of the MRP application to send the requested
information using HP Sockets .

The FC application provides a 4GL for application developers to
customize their application. We will write a few functions in this 4GL
to interact with the FC adapter to get data from and send data to the
application. The functions can directly access the FC application\xd5s
variables and database to allow us a lot of flexibility and capability
within the integrated solution. Since most of the work can be passed
off to the FC functions, we will write one "send and receive" adapter
for this application.


*** Object: Untitled


Refer to the System Overview diagram on the previous page for a picture
of the adapter design for the integrated solution. The boxes with the
thick lines show the integration pieces being written for this
solution. In conjunction with designing the adapters, we also need to
determine the transfer mechanism to be used to retrieve and store the
data for each data flow. Here are the transfer mechanisms for the three
data flows we examined in the "Define Data Access and Control" section.
As you will see, this step requires detailed knowledge of the
import/export features of the applications.

Data Flow: 1B Name: Finished Goods Inventory (FGI) Push/Pull: Pull
Trigger: SCHD Operator Source: MRP database accessed by procedures
written in MRP\xd5s 4GL Destination: SCHD in memory table accessed by
SCHD\xd5s batch import mechanism Transfer Mechanism: message

1) Operator presses function key which triggers a SCHD procedure to
execute the SCHD "send" adapter to send message to MRP to get FGI.

2) MRP "receive" adapter gets FGI data request message, parses message,
and formats it for the Interface Manager and sends it off.

3) Interface Manager triggers appropriate extract procedure and sends
data to the MRP "send" adapter.

4) MRP "send" adapter sends data to SCHD "receive" adapter.

5) SCHD "receive" adapter writes data to a file until all of the data
is received and then closes the file.

6) SCHD auxiliary program (Notify) recognizes that the input file
exists and in forms the operator who then imports the data using SCHD
functions.

Data Flow: 3A Name: Production Plan Push/Pull: Push Trigger: Solution-
based event: completion of production plan Source: SCHD in memory table
accessed by SCHD batch export mechanism Destination: MRP database
accessed by procedures written in MRP 4GL Transfer Mechanism: message

1) Operator presses function key which triggers a SCHD procedure to
store the production plan into a file and execute the SCHD "send"
adapter with the name of the file.

2) SCHD "send" adapter reads the file and sends the data as a series of
messages to the MRP "receive" adapter.

3) MRP "receive" adapter reads the messages, formats the data and sends
it to the Interface Manager via the pipe.

4) The Interface Manager stores the data into the MRP database.

Data Flow: 8A Name: Recipe Push/Pull: Pull Trigger: Solution-based
event: evaluation of the production schedule Source: MRP database
accessed by procedures written in MRP 4GL Destination: FC shared memory
accessed by procedures written in FC 4GL Transfer Mechanism: message

1) 4GL function is invoked if FC needs the recipe to produce a part in
its new production schedule.

2) Function causes FC "send" adapter to send a request message to the
MRP "receive" adapter for the recipe.

3) MRP "receive" adapter reads the message, formats the data and sends
it to the Interface Manager via the pipe.

4) The Interface Manager uses a function to get the recipe data and
trigger the MRP "send" adapter to send the recipe to the FC "send and
receive" adapter.

5) FC "send and receive" adapter receives the recipe and uses a 4GL
function to store it in FC shared memory.


3.5     Create Detailed Data Definition

At this point in creating our integration solution, we know each data
flow that is required, where the data is coming from and going to, and
the steps required to access and transfer that data. We now have to
examine the data at both the producing and consuming ends in more
detail to answer the following questions:

What are the data elements at each end of the data flow and what
information do they represent?
What are the data types of each of those elements and what programming
language is used to create or consume that data?
What types of manipulations must be performed on the data to get it
from its source to destination format?
Where and how will those manipulations be performed?

Answering the first two questions requires detailed knowledge of the
applications.  There are no tricks involved in this step - simply
investigative work into the applications producing and consuming the
data.  Most of the integrated solutions in existence today pass ASCII
data since it is the only data type compatible between programming
languages and computer architectures. With HP Sockets, you are free to
pass the data in its native format, whether that be ASCII or binary,
since HP Sockets can correct for programming language and computer
architecture differences when passing binary data. You simply have to
know which programming language is used to product and consume the data
so HP Sockets can do the correct transformations.

Once the data elements and their types are defined, answering the third
question is straightforward. If the data elements are the same on both
the producing and consuming end in order and data type, you do not need
any data manipulation. If the data elements are different, determine if
HP Sockets supports the conversions necessary. If it does, you can
define the data definitions and manipulations in the configuration
files and HP Sockets will perform the conversions when the data is
sent. If the manipulations are message content based or HP Sockets does
not support th e necessary data structures, either the sending or
receiving adapter must perform the necessary conversions. When the data
being passed is ASCII data of variable length, the adapters must
perform any data conversions required. If you can define a maximum
length for the data, HP Sockets can manipulate it. Generally, the
receiving adapter is designed to do any data manipulations required
since it best knows the data format that its application requires.The
HP Software Integration Sockets Adapter Architecture document describes
a generic way to write the receiving adapter for it to convert the
incoming data into its application format.

The information gathered at this step should be added to each of the
data flow specifications. These data flow specifications will be used
to develop the contents of the HP Sockets configuration files and the
adapters in the next step.


3.5.1   Example

We will do the detailed data design for data flows 1B and 3A.  This
example will fill out the last two fields in the data flow
specification form

Data Flow: 1B Name: Finished Goods Inventory (FGI) Source Data Format:
Series of records containing the following two fields:

1) Product - part number of the inventory product - up to 16 ASCII
characters

2) Quantity - quantity of inventory available for this part - variable
length ASCII field Destination Data Format:

1)      Product - part number of the inventory product - variable
length ASCII field
2)      Quantity - quantity of inventory available for this part -
variable length ASCII field Data Manipulation: none

Data Flow: 3A Name: Production Plan Source Data Format: Series of
records
containing the following fields:

1) Date - date when the product quantity will be available - ASCII
field in the format MMDDYYYYHHMMSS.
2) Product - part number of the inventory product - up to 16 ASCII
characters
3) Quantity - quantity of inventory that will be available for this
part -variable length ASCII field Destination Data Format:
1) Date - date when product quantity will be available - Six blank
separated ASCII fields in the format YYYY MM DD HH MM SS.
2) Product - part number of the inventory product - up to 16 ASCII
characters
3) Quantity - quantity of inventory that will be available for this
product - variable length ASCII field Data Manipulation: HP Sockets
manipulation of the first field (source and destination programming
languages are C); no manipulation of the other two fields


3.6     Create Configuration Files and Adapters

Creating the HP Sockets configuration files is really just transferring
the data that you gathered through all of these previous application
integration steps into the appropriate configuration file and format.
Forms exist to help you organize the information gathered to make it
easy to create the configuration files. For a copy of those forms and
the details of the format of the configuration files, refer to the HP
Software Integration Sockets Programmer Manual.

You must fill out the Network Definition and Process Definition
configuration files to define the adapters and machines in your
network. To do this, map the adapters you defined in the "Design
Adapters" section onto machines. You should pick logical names for your
adapters that reflect the functionality of the applic ation rather than
the name of the application. By doing this, you can swap the
application and still have configuration files that accurately reflect
the integrated solution.

The Data Definition, Data Manipulation Definition, and Link Definition
files only have to be filled out if you decided your data needed to be
manipulated by HP Sockets during the "Create Detailed Data Definition"
step.

The File Definition file only has to be filled out if you chose a file
transfer mechanism for any of the data flows during the "Design
Adapters" step.

An entire design document, HP Software Integration Sockets Adapter
Architecture, exists to guide you in writing your application adapters.
It covers the layout of an adapter, how to communicate correctly with
HP Sockets, how to detect and report errors in a standard manner, how
to parse and interpret the standard messages that arrive, etc. Use it
together with the information gathered in the previous steps to write
your adapters.


3.7     Test and Debug Solution

The HP Sockets Manager Command Processor allows you to test your
solution in small steps to fix problems early in the development cycle.

First, you should validate your configuration files using the HP
Sockets Manager validate command. Validation detects any syntactic or
semantic errors in your files. Refer to the HP Sockets manuals for help
in this area. Once your configuration files are validated, use two
session of the Command Processor to test your configuration by
simulating each of the adapters. In the first session, initiate
communication with HP Sockets as the first adapter with the init
command and send a message to the second adapter with the enterbuf and
sendmsg commands. In the second session, initiate communication with HP
Sockets as the second adapter with the init command and read the
incoming message with the readq and displaybuf commands.

Next your application adapters should be compiled using the appropriate
compiler for the language in which you wrote them. As each adapter is
compiled, you can test its logic with the Command Processor by
initializing as one of the adapters that it will communicate with and
exchanging messages with it.

At this stage you have unit tested each of the pieces of the solution
that interact with HP Sockets. What you have left to do is test the
interaction between the adapters and their applications and test the
complete integrated solution.

Some common problems encountered during testing are:

* Your adapter cannot initiate communication with HP Sockets. Check the
error log file for messages about missing information or incorrect
logical process names. You probably have an inconsistency in your
Network and/or Process Definition files.

 * Two adapters on two different machines cannot communicate with one
another. First, verify that the networking between the machines is set
up correctly by using some of the networking services. If the
networking is correct, send messages between the Command Processor on
each of the two machines to determine if HP Sockets is operating
correctly.

* The data received by an adapter is incorrect. Check your data, data
manipulation, and link definitions to make sure you have accurately
represented the data that is being passed. You should check items such
as the data types, data lengths, and variable names.


3.8     Put Integrated Solution into Production

Before putting your integrated solution into production, there are a
number of a dditional questions that need to be addressed. The answers
to these questions a re very dependent on the particular solution and
environment the solution will run in.

     How will the HP Sockets Management Daemon, smd, be started when
the machine is booted? A nice solution is to start the smd from a run
file that is invoked when the machine is booted.

     How will HP Sockets, the adapters, and the applications be started
up and shut down in order to be synchronized properly? You probably
want to have a script or command file that contains the necessary HP
Sockets Manager commands to both start up and shut down the HP Sockets
domain. You need to decide the appropriate method and order for
starting and stopping the applications and adapters.

     How do the configuration files need to be changed to move from the
development environment to the production environment? The names and
addresses of the machines will probably be different in the production
environment. Make the appropriate changes to the Network Definition
file and validate it before starting up HP Sockets in the production
environment.

     What should be done with HP Sockets when the machine is being
backed up? If you take down the networking services when a back up is
performed, be sure to gracefully shut down HP Sockets first. If you can
leave the networking services running, HP Sockets can be left running
during the backup.


     Are the default timeouts adequate for your solution? If you are
running a doma in containing MPE XL nodes or are running over a WAN
with long delays, you may have to increase the event and message
passing timeout values so HP Sockets does not time out. These values
can be changed with the changeparms command in the HP Sockets Manager.


4.0     Full Functioned Adapter

The previous chapter discussed the steps to create an integrated
solution. Often times though, an adapter is written for an application
independent of a final solution that the adapter may be used in. In
these cases, a full functioned adapter should be written. A full
functioned adapter provides an HP Sockets-based message interface to
all of the functions of its application that can be accessed with any
of its other interfaces. These functions include requests for data ,
requests for an action, and storage of incoming data. By providing this
adapter, or set of adapters, the application can be easily plugged into
a new HP Sockets-based solution without changes to the adapter. To
ensure that these full functioned adapters can really be plugged
together, they must communicate using the standard message format
defined in the HP Software Integration Sockets Standard Message Format
document. By defining the messages that your adapter can accept, you
are providing system integrators with a specification for hooking your
application up to others to provide a new set of features to the user.


5.0     Documentation Roadmap

The HP Sockets Program can provide you with a series of documents to
help you discover the benefits, features, and technical aspects of
using HP Sockets for your application integration needs. Here is a
roadmap of these resources that are available to you.

HP Sockets Product Manuals:

HP Software Integration Sockets Self-Paced Tutorial for HP-UX. Tutorial
for the technical implementor of an HP Sockets-based solution on HP-UX.
(Available from HP: 92568-90003)

HP Software Integration Sockets Self-Paced Tutorial for MPE XL.
Tutorial for the technical implementor of an HP Sockets-based solution
on MPE XL. (Available from HP: 92616-90004)

HP Software Integration Sockets System Administrator Manual.  Manual
for the administrator of an HP Sockets domain.  (Available from HP:
92568-90002)

HP Software Integration Sockets Programmer Manual. Manual for the
technical imp lementor of an HP Sockets-based solution. (Available from
HP: 92568-90001)

HP Software Integration Sockets Access Routine Reference. Reference
manual for the technical implementor of an HP Sockets-based solution.
(Available from HP: 92568-90025)

Application Notes:

Application Integration Using HP Sockets. Application integration steps
for the designer of an HP Sockets-based solution. (Available from CCSY
Hotline; subject: index)

HP Software Integration Sockets Standard Message Format. HP Sockets
Program defined message format for the technical implementor of an
application adapter. (Available from CCSY Hotline; subject: index)

HP Software Integration Sockets Adapter Architecture. Suggested
architecture an d sample code of an application adapter for the
technical implementor. (Available from CCSY Hotline; subject: index)

Connecting Foreign Host Applications to HP Sockets using NCS. A design
for usin g the Network Computing System (NCS) to establish
communication between applications running within an HP Sockets domain
and an application running on a platform which is supported by NCS but
not by HP Sockets. (Available from CCSY Hotline; subject: index)